home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 6 / CU Amiga Magazine's Super CD-ROM 06 (1996)(EMAP Images)(GB)(Track 1 of 4)[!][issue 1997-01].iso / cucd / online / fidonetts / fsc-0055.001 < prev    next >
Text File  |  1991-03-31  |  4KB  |  97 lines
  1. Document: FSC-0055
  2. Version:  001
  3. Revision: 31-Mar-1991
  4.  
  5.  
  6.  
  7.  
  8.              Security Passwords in Nodelist Update Files
  9.  
  10.                              Luke Kolin,
  11.                1:250/714@fidonet.org, 89:480/210@imex
  12.  
  13.                           March 31st, 1991
  14.  
  15.  
  16.     Status of this document:
  17.  
  18.          This FSC suggests a proposed protocol for the FidoNet(r)
  19.      community,  and requests discussion and suggestions for
  20.      improvements.  Distribution of this document is subject
  21.      to the restrictions listed below.
  22.  
  23.          Fido and FidoNet are registered marks of Tom Jennings
  24.          and Fido Software.
  25.  
  26.          The author grants the FTSC unlimited  distribution and
  27.          reproduction rights  in order to facilitate discussion
  28.          of the proposals in this document.
  29.  
  30.          MakeNL is a program by Ben Baker.
  31.  
  32.          SysNL is a program by Luke Kolin.
  33.  
  34.  
  35.  
  36.   PURPOSE
  37.  
  38.     This document is intended to explain the format and purpose of
  39.   security passwords within nodelist update files, and to inform the
  40.   authors of nodelist software about its proper usage.
  41.  
  42.  
  43.   THE NEED FOR PASSWORDS
  44.  
  45.     Until now, the nodelist update files that *Cs create with software
  46.   packages such as MakeNL or SysNL have had no security passwords inside
  47.   of them. The only security between the NC and an RC has been the name
  48.   of the update file itself. For example, the name of the Net 250 update
  49.   file was "Metronet.250". It was quite conceivable for a sysop, upon
  50.   discovering this name, to make a fraudulent update file, also called
  51.   "MetroNet.250", and send this to 1:12/0. The nodelist processor which
  52.   created the regional update file at that end would not know that the
  53.   file was not genuine, and this would be added to the weekly update for
  54.   the region.
  55.  
  56.  
  57.   PASSWORD FORMAT
  58.  
  59.     It seems emminently logical that some sort of security password
  60.   should be added to nodelist update files, to prevent the aforementioned
  61.   problems from occurring. Therefore, I propose that nodelist update files
  62.   have an optional password in the first (header) line, right after the
  63.   ";A" general interest flag. The first character of this case-sensitive
  64.   password shall be an "at" sign @ (ASCII decimal 64 hex 40). If this
  65.   character is present, then all characters after it, until (but not
  66.   including) the next space (ASCII decimal 32 hex 20) will be considered
  67.   part of the password. As well, no password may be 8 characters or more
  68.   in length. This is a sample header line, with a password of ConSoft
  69.   present:
  70.  
  71.   ;A @ConSoft Net 250 nodelist file for Friday, February 22nd : 10344
  72.  
  73.     Please note the password starts right after the first space (ASCII 
  74.   32) with the ASCII 64 decimal character, and is case-sensitive. The
  75.   following is a sample header, without a password present:
  76.  
  77.   ;A Net 250 nodelist file for Friday, March 1st : 13501
  78.  
  79.  
  80.   NOTES
  81.  
  82.     It is extremely important that the password be on the first line
  83.   of the nodelist update file. It must commence immediately after the first
  84.   space (ASCII 32) character, with an ASCII 64 "at" sign. Remember, it is
  85.   case-sensitive.
  86.  
  87.     I believe that it is up to the authors of individual nodelist
  88.   utilities to deal with the presence of passworded update files as they
  89.   believe fit. However, it is my belief that utilities, when faced with
  90.   a file with a bad password, retain a copy of a previous (good) update
  91.   file, which should be used instead of the bad one, to prevent the equally
  92.   nasty problem of a bad update file preventing an entire network/region
  93.   from being included.
  94.  
  95.     Please note that I do not participate in either the FTSC or NET_DEV
  96.   conferences. I can be reached at 1:250/714@fidonet.org, or in Imex at
  97.   89:480/210@imex.